perf(agc): pre-sync the DCC key writers of a dispatch's images before the GPU mutex - #6631

What

Companion: #6632 (independent of this one; the two together give more than the sum, see Tested).

A compute dispatch builds its resources in two stages: stage A (binding plan, buffers, descriptor set) runs without the GPU mutex, stage B (the image lookups) under it. Between them VulkanDevice::presync waits, still without the mutex, for recorded GPU work that writes a surface stage B would read on the CPU, so that the locked lookup finds nothing pending and the other workers do not queue behind the wait. That list held only the texel surfaces. The DCC keys of an image are read on the CPU as well (TextureClearKeys, the clear-code decode of a sampled texture or a storage image), and when recorded work writes them with values the driver can't derive from the pending stores, WaitForKeyWriters synchronizes with the GPU under the mutex.

In Minecraft Dungeons II (PPSA16064) on its title screen (3840x2160, about 8 FPS) the pre-sync fired once in 296,000 dispatch checks while WaitForKeyWriters synchronized 400 times per 10 s, 1.17 s of waiting under the mutex per 10 s, about 90 % of it on the compute queue worker. The queue 0 worker and the draw committer waited 2.6 s per 10 s behind exactly the compute worker's holds.

• Graphics::PresyncSurface (address, bytes, dccKeys) replaces the (address, bytes) pair that ShaderResources::PresyncSurfaces, Recipe::presyncSurfaces and VulkanDevice::presync passed around.
• PresyncSurfaces adds the key range (one key byte per 256 surface bytes, DccKeyBytes) of every image binding with a DCC address, for the built object, the cached object and the address-based decode alike.
• presync waits for a key range only while recorded work writes it (the lock-free pending-write snapshot), no key-store memo entry already gives its value (Graphics::DccKeyWritersPending, the same memo PendingStoreKeys consults) and, under the mutex it takes for a moment anyway, the pending stores do not give the keys either (Graphics::DccKeyWriterNeedsSync: a pending write overlaps and PendingStoreKeys has no value, the test WaitForKeyWriters makes before it synchronizes). Which keys a dispatch reads, and when, is unchanged: the locked lookup runs as before and finds nothing pending. A writer recorded after the check still takes the locked wait.
• The [presync] line (APS5_PROFILE_DRAW) counts key ranges checked, pre-syncs that only the keys required, and the outcomes of WaitForKeyWriters (no pending writer, keys known, fills leaving uncompressed, synchronized). VulkanDevice::PresyncCounts() exposes the first two for the test.
• APS5_NO_DCC_PRESYNC=1 leaves the key ranges out (APS5_NO_PRESYNC=1 already disables the whole pre-sync). docs/dev/ARCHITECTURE.md: one paragraph on stage A, the pre-sync and the key ranges.

Tested

Windows 11, MinGW-w64 GCC 15.2, NVIDIA GeForce RTX 5070 Laptop GPU (driver 617.42) for the title rows; lavapipe on Linux CI for the tests. The title rows ran on this change on top of 44df21632; the branch is squashed onto 5d9dcc42d (the 59 commits in between merge without a conflict and the changed lines are the same).

• Test agc_driver_dcc_key_presync (new): a kernel that copies data over the DCC keys of a sampled texture is recorded. Control: a dispatch built under the mutex waits for it in WaitForKeyWriters (synced rises). With PrepareDispatch: stage A lists the key range and waits once before the mutex (PresyncCounts: keyChecks, keyWaits, presyncs), the dispatch then makes no locked synchronization, and both samples read the same keys (the texture reads as the 0000 clear the kernel stored). A second PrepareDispatch with nothing pending waits for nothing, and one behind a recorded constant fill of the keys, whose value the pending stores give, waits for nothing and the dispatch makes no locked synchronization either. The test skips with the reasons tools/check_skips.py expects when the device has no timeline semaphores or no host import. Fork CI (Linux, lavapipe, ubuntu-latest; this squashed head on origin/main 5d9dcc42d): https://github.com/AlxcBTW/AnyPS5/actions/runs/38817872674, 459 of 459 tests of ^(agc_driver_|agc_recorder|agc_dcc|agc_display_buffer_dcc|agc_pending|agc_key) pass, agc_driver_dcc_key_presync in 0.15 s.
• Build: Windows libs and relinker compile on the fork CI (MinGW-w64 GCC): https://github.com/AlxcBTW/AnyPS5/actions/runs/38817909024 (this squashed head). tools/check_conventions.py --base origin/main passes.
• Title rows (Minecraft Dungeons II title screen, 3840x2160, 150 s rows, the first three 10 s windows of each row dropped, APS5_TEXTURE_CACHE_MIB=3072, APS5_PROFILE_DRAW=1, APS5_PROFILE_GPU=1, APS5_NO_PAD_INPUT=1; the main arm is the binary with both switches off, which an earlier session measured against a build of origin/main: 7.80 against 7.93 FPS):

Rows run in the order both, this PR, companion, main, main, companion, this PR, both. The warm-up row and the first both row, the first two after the relink, found no title windows (probably cold caches), so both has one row of eight windows. Rows of identical code differ by up to 0.8 FPS (the two main rows read 7.08 and 7.62, the two rows of the companion alone 7.16 and 7.97), about 10 %, so a single row cannot resolve an effect of that size; the pooled arms and the repetition in other sessions can. The same scene on the same machine in two earlier sessions: origin/main against the first commit of this PR with the companion, alternating rows, 7.93 against 8.76 FPS (+10.5 %); an earlier lab build, levers off against both levers on, 7.94 against 8.76 (+10.2 %), with this PR's lever alone at +2.6 % and the companion's alone at +2.9 %. The baseline therefore lands between 7.35 and 7.94 FPS from session to session, and the changed build between 8.55 and 8.76 FPS: +10 % to +16 %, +12 % on average of the three sessions. Alone, this PR gives +2.6 % and +4.0 %, the companion +2.9 % and +3.0 %; together they give more than the sum, and the GPU busy time stays at about 80 ms while its idle time per frame falls from 54.7 to 36.3 ms.

• Performance report protocol (the scene ran once and the title was restarted, so the caches are warm; only APS5_TRACE_SECONDS=60:10 is set besides APS5_TEXTURE_CACHE_MIB=3072, APS5_NO_PAD_INPUT=1 and the trace directory; same machine, scene and session, one capture per build, no event dropped): origin/main, 81 presents in 10.0 s = 8.09 FPS, frame time p50 120.7 / p90 138.8 / p99 152.7 ms, GPU busy 79.2 ms; both PRs, 80 presents in 10.0 s = 7.97 FPS, p50 120.1 / p90 153.0 / p99 176.4 ms, GPU busy 78.5 ms. These two captures do not show the difference: a capture is 80 frames of one row, and rows of identical code differ by more than the effect (see above). The captures of the earlier session (20 s, APS5_TRACE_SECONDS=60:20, the queue 0 worker's event buffer full after 12 s, so they are flagged trace_dropped) read 8.27 FPS (p99 151.9 ms) for origin/main and 8.99 FPS (p99 130.6 ms) for the first commit of this PR with the companion (+8.7 %). The summary lines of the four captures follow as a comment; the traces are kept and available on request.
• Not checked: other titles, other GPUs and drivers, macOS. The pre-sync still waits where only PendingFillsLeaveUncompressed would have answered in the locked lookup (it needs the texture's key encoding, which the surface list does not carry; the counter of those answers was 0 in every row), and it skips a range whose key-store memo entry is older than a later unknown writer (the locked lookup then waits as before).

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• Unblocks: none
• GPUs tested: NVIDIA GeForce RTX 5070 Laptop GPU, driver 617.42, Windows 11 (title rows); lavapipe (Mesa) on ubuntu-latest (tests)
• AI-assisted: yes